Communication protocols play a central role in today's information systems. The wide spread use of the Transmission Control Protocol/Internet Protocol (TCP/IP) protocol and the rapid development of communication technologies laid the ground for an explosion in the use of information technologies at homes, businesses and government agencies. Several protocols, including TCP/IP, HTTP, SMTP, S/MIME, SSL and IPsec, have contributed to this growth. Moreover, new technologies are emerging frequently to support the growing need for efficient, easy and secure communication.
Developed in the mid-1970's by the Defense Advanced Research Project Agency (DARPA) of the U.S. Department of Defense, the TCP/IP protocol has several features that led to its widespread adoption: open standard, freely available for developers and independent of any specific physical network hardware. The first two features led to TCP/IP's wide acceptance, and the latter feature made it easy for different kinds of networks to interoperate. With the adoption of TCP/IP, the Internet has seen an exponential growth.
The TCP/IP stack consists of four layers: the network access layer, the Internet Protocol layer (IP), the transport layer and the application layer. The network access layer is located at the bottom of the architecture. It consists of many protocols that provide access to physical networks. Compared to the Open System Interconnection (OSI) seven-layer reference model, the network access layer comprises just two layers: a data link layer and a physical layer.
The IP layer is responsible for defining the Internet addressing scheme, composing datagrams and routing them to their destination. IP is a connectionless protocol. Yet, it does not provide handshake or reliability mechanisms. Thus, IP depends on other layers to provide such services.
The transport layer consists of two protocols: Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). TCP provides connection management reliability, flow control and sequencing, whereas UDP serves as a simple interface between applications and IP. One other distinction is that UDP does not provide reliability, flow-control or error-recovery.
The application layer is at the top of the stack. It includes protocols that use the transport layer to deliver data to the network. Many protocols run at the application layer to provide services such as TELNET, HTTP, SMT and FTP.
Problematically, TCP/IP does not have security measures to support the kind of applications that have appeared over time. Therefore, several security solutions have been proposed to address the different kinds of vulnerabilities of TCP/IP, as well as the additional security needs of applications. Such security solutions are typically associated with a single layer of the TCP/IP stack or with specific applications.
Security protocols also play a central role in today's information systems. Most tend to have more commonalities than differences. For example, security protocols share significant functionality and utilize a common set of encryption, hash and compression algorithms. They usually differ in the handshaking mechanism (which includes authentication), target data, header processing, key sizes, replay mechanisms and the order in which the various algorithms are applied.
One common security protocol is the secure socket layer (SSL). The motivation for the SSL protocol development was to provide protection to electronic commerce and Web transactions. In 1994, Netscape communications introduced SSL version 1.0 in its Mosaic Web browser. Netscape made SSL an open standard and encouraged the Web community to participate in its development. Later, in May 1996, the development of SSL became the responsibility of the Internet Engineering Task Force (IETF), which was later renamed as Transport Layer Security (TLS).
SSL has two important features. First, it provides strong protection based on public key cryptography. That is, SSL uses public key cryptography to encrypt the pre-master key that is used to generate the set of shared keys. Second, SSL is efficient because it uses symmetric key cryptography to protect the traffic between the communicating parties. Therefore, SSL consumes relatively little CPU time to protect the exchange of data between parties. These two features made SSL suitable for most e-commerce applications on the Internet.
Today, SSL is the most widely used Web security protocol. Almost every browser and Web server supports SSL. SSL adds security by inserting itself between the Hypertext Transfer Protocol (HTTP) application and the TCP layer. Therefore, SSL requires minor changes in the applications. In addition, SSL is not limited to HTTP traffic (through its original specification) but it can support other Internet applications, such as Net News, FTP and Telnet.
However, a disadvantage of SSL is that it only supports TCP. In the typical handshake process, an SSL initiator sends to the second party a list of the security capabilities that it can support. For instance, TLS v.1 currently supports 32 different capabilities. In this format, the responder selects his preferred capability and sends it back to the initiator along with a certificate that contains a public key. The certificate is then used by the initiator to authenticate the responder. Next, the initiator creates a pre-master secret key, encrypts it with the responder's public key and sends the encrypted message to the responder. Afterwards, both parties use the pre-master secret key to create six shared keys for the protection of the subsequent communication. Each party indicates its readiness to switch to protected mode by sending a single byte message called ChangeCipherSpec. The first protected message sent by each party is the Finish message. This message contains a hash value of all the previously exchanged messages between the parties to protect the session against replay attacks.
Another security protocol is IP Security Protocol (IPsec). IPsec is a security standard developed by the Internet Engineering Task Force (IETF). This protocol is designed to establish a solid security ground for the Internet. IPsec is part of the Next Generation Internet or Internet II (IPv6). Most of the VPN products nowadays adopt the IPsec protocol (e.g., Cisco VPN, eTrust, VPN-1 and Symantec). A complex technology, IPsec's main goal is to secure the flow of information between two endpoints. Its security services are designed for the IP layer. Furthermore, it provides several types of protections such as source IP authentication, integrity and confidentiality. The protection scope varies. For example, it may include the IP header, or it may be limited to the payload only. These choices are determined by a set of security policies that are managed by a system administrator. However, an IPsec-secured connection is very cumbersome to setup and configure because it comes in many varieties. Therefore, an IPsec user has to have a clear set of requirements and security policies before implementation. Otherwise, it would be hard to validate whether there is a secure connection or not.
IPsec consists of two major protocols: Authentication Header (AH) and Encapsulating Security Payload (ESP). Each protocol can be configured to run in Transport Mode or in Tunnel Mode. The Transport Mode provides security for transport layer (TCP, UDP or ICMP). Typically, this mode is used for end-to-end communication. Therefore, ESP in transport mode encrypts, and optionally authenticates, the IP payload but not the IP header. Similarly, AH in transport mode authenticates the IP payload and selected portions of the IP header without encryption.
Tunnel mode provides security for the entire packet. A new header with the gateway destination address is added to the packet. ESP in tunnel mode adds a new header to the packet, encrypts it and optionally authenticates the new packet including the new header. In contrast, AH in tunnel mode authenticates the entire packet and parts of the new header without encryption.
IPsec manages keys and establishes sessions through a protocol called the Internet Key Exchange (IKE). IKE is a collection of protocols: Internet Security Association and Key Management Protocol (ISAKMP), Oakley Key Determination Protocol (Oakley) and Secure Key Exchange Mechanism (SKEME). Therefore, IPsec supports a wide variety of key types and sizes.
IPsec provides general IP security services regardless of the specific needs of the applications. However, IPsec is transparent to applications. Therefore, similar to SSL, IPsec cannot address specific needs of an application, such as authenticating a user or protecting parts of a document (e.g., part of a contract or a payment document).
The current approach to implementing security protocols is centered on designing a protocol as a single package comprised of two layers: control and a library of algorithms. This approach is based on the assumption that every protocol is complete and does not need to be integrated with other security protocols. Yet, this assumption may not be valid in situations where several security protocols need to coexist. In such cases, redundancy and conflicts may occur. For example, running Secure/Multipurpose Internet Mail Extensions (S/MIME) over IPsec introduces redundancy. Both provide similar encryption: S/MIME does it at the document level and IPsec at the packet level. This situation is common in business-to-business (B2B) applications when an application uses S/MIME as a document-level protection while using IPsec to protect the communication with a remote branch office.
Moreover, the current approach of designing autonomous and complete protocols has several disadvantages. First, it may result in conflicts when various protocols need to coexist. For example, if compression is done at an upper layer (e.g., S/MIME), repeating it at a lower layer may increase the size of the message. Second, there is not enough flexibility in most security protocols (e.g., S/MIME, SSL, IPsec) and, consequently, their users have to adopt them without being able to make changes. For instance, a user may want to change the header by adding or removing some fields for quality of service (QoS) purposes. Third, these protocols offer coarse grained security services and the developer of an application does not have the ability to fine tune operations within the use of these protocols. For example, S/MIME services are applied to an entire document, preventing a user from applying it on selective parts of the document. Fourth, the use of coarse grain services may lead to unnecessary performance degradation. For instance, SSL has to calculate a block of four shared keys and a couple of IVs even if the user does not want to use some of the modes such as the read mode, the write mode, the encryption service or the integrity service.
Furthermore, the traditional approach to implementing protocols is monolithic. Adhering to monolithic protocols limits users to situations for which the protocols were implemented. Internet applications and their security requirements are evolving very rapidly. Video, audio, wireless applications, collaborative applications and many other emerging technologies raise new challenges and require flexible approaches to deal with them. This monolithic implementation approach is not well-suited to cope with rapid changes in communication and security requirements.
Overall, the current process of implementing a protocol is tedious and error-prone. Protocol specifications in natural language are often ambiguous and may lead to defective implementations. Moreover, implementations have to be thoroughly tested. This testing is a time-consuming effort due to the timing dependencies of events processed by protocols.
Consequently, it would be desirable to have a model for sharing protocol specifications to produce protocol implementations automatically. It would also be desirable to free protocols from being dependent on the monolithic implementation of a limited number of capabilities. Additionally, it would be desirable to have a flexible infrastructure for businesses to exchange protocol specifications and automatically generate code that supports the evolving B2B environment. Furthermore, it would be desirable to have a framework that could be applied to overlay networks and Web Services.